F/e  17/2 


AD-A080  609 
UNCLASSIFIED 


HONEYWELL  SYSTEMS  AND  RESEARCH  CENTER  MINNEAPOLIS  MN 
SYSTEM  CONTROL  FOR  THE  TRANSITIONAL  DCS.(U) 

MAY  78  R  K  CROWE*  D  E  DOTY*  R  L  TUFANER  DCA100-78-C-0017 

78SRC52  _  SBIE-AD-E100  325  _ NL 


_ UNCLASSIFIED  Mav  1978  ^ 

SECURITY  CLASSIFICATION  OF  THIS  PAGE  (When  Data  Entered) 


REPORT  DOCUMENTATION  PAGE 


.  REPORT  NUMBER 
flno  S' 


READ  INSTRUCTIONS 
BEFORE  COMPLETING  FORM 


EClPIENT'S  CATALOG  NUMBER 


)  System^ Control  for  the  Transitional  DCS  *  ( 
Technical  Report  Number  1 


rowe 
D.  E./feoty 
R.  L./Tufaner 


c^ESCe 


10.  PROGRAM  ELEMENT.  PROJECT.  TASK 
AREA  ft  WORK  UNIT  NUMBERS 


Mail 


13.  NUMBER  OF  PAGES 

58 


11.  CONTROLLING  OFFICE  NAME  AND  ADDRESS 

Defense  Communications  Agency  -  DCEC  -  R310 
1860  Wiehle  Avenue 
Reston,  V A  22090 


1«.  MONITORING  AGENCY  NAME  ft  Unparirflf  . . I  . .  IT . IHn<  OW i  nl  IS.  SECURITY  CLASS,  fof  Hii»  report) 

UNCLASSIFIED 


15a.  DECLASSIFICATION/ DOWNGRADING 
SCHEDULE 


16-  DISTRIBUTION  STATEMENT  (ol  thla  Report) 


Approved  for  Public  Release  -  Distributlfia-UolillLitefl 


17.  DISTRIBUTION  STATEMENT  (of  the  abstract  endued  In  BtTTck  it  dt  tferenTTrdth  ~R9pot  1)  -  - — - 

'  (■  ’I;  C  L - - - 


19.  KEY  WORDS  (Continue  on  revet 

DCS 

deployment  model 
stress  scenarios 
control  responses 


aide  it  neceeamry  end  identity  by  block  number) 

terrestrial  and  satellite  transmission  control 
common  user  network  control 
system  control 


ZO,  ABSTRACT  (Continue  on  reverae  aide  It  neceaaary  and  Identity  by  block  number) 

rThls  report,  the  first  of  four  required  under  two  tasks,  documents  the  model 
of  the  European  Defense  Communications  System  in  the  mid  1980  time  frame  arhd 
presents  a  set  of  stress  scenarios  from  which  requirements  for  network  and 
traffic  controls  will  be  derived.  The  scenarios  include  Isolated  and  inter¬ 
dependent  events  of  failures,  unusual  traffic  conditions  and  other  system 
degradations.  The  report  Includes  addressal  of  the  DCS  AUT0SEV0C0M  II  network 
which  is  no  longer  valid. 


FORM 
1  JAN  73 


EDITION  OF  1  NOV  65  IS  OBSOLETE 

V0Z  3V? 


_ UNCLASSIFIED _ In¬ 
security  CLASSIFICATION  OF  THIS  PAGE  (Wien  Dete  I 


Table  of  Contents 


Page  Number 


1 . 0  Introduction  1 

2 . 0  Deployment  Model  4 

2.1  Purpose  of  the  Deployment  Model  4 

2.2  Assumptions  4 

2.2.1  Time  Frame  4 

2.2.2  Geographical  Area  5 

2.2.3  Communications  Equipment  5 

2.2.4  Performance  Monitoring  Equipment  6 

2.3  Deployment  Model  Data  6 

2.3.1  European  Backbone  Topology  6 

2.3.2  Common  User  Network  Connectivity  9 

2.3.3  Critical  User  Deployment  12 

2.3.4  ATEC  Overlay  16 

2.3.5  Model  Segment  Detail  18 

3.0  Stress  Scenarios  22 

3.1  Purpose  of  Stress  Scenarios  22 

3.2  Stress  Scenario  Creation  Methodology  22 

3.3  Use  of  Scenarios  25 

3.4  Introduction  to  Scenario  Data  27 

3.4.1  Introduction  to  Scenario  Data  28 

3.4.2  Scenario  List  35 

3.4.3  Stress  Scenario  Details  43 


ACCESSION  for  V 

NTIS 

DOC 

UNANNOUN 

J0ST1FICAT 

White  Section^ 
Buff  Section  □ 
CEO  □ 

Off 

BY 

mm 

flVHJKMUn  CODES 

font,  avail  and/or  srtswU 

m 

lJ 

List  of  Illustrations 


Page  Number 


2-1 

European  DCS  Backbone  Model  1982-85 

8 

2-2 

Radio  Link  Overlay 

10 

2-3 

European  AUTOVON-AUTODIN  1ST  Connectivity 

11 

2-4 

AUTOVON- AUTODIN  1ST  Backbone  Overlay 

14 

2-5 

Critical  User  Deployment 

15 

2-6 

ATEC  Overlay 

17 

2-7 

Model  Segment  Detail 

19 

3-1 

Scenario  Selection  Matrix 

List  of  Tables 

2-1  AUTOVON/AUTOSEVOCOM  Trunk  Group  Information  13 
2-2  vaihingen  User  Circuits  20 
2-3  Link  Circuit  Breakout  21 


M*4t  J»iK*C Hi*fc  U>.  Nt»  3 


SECTION  I.  INTRODUCTION 

This  is  the  first  Technical  report  for  the  System  Control  for 
the  Transitional  DCS  study.  The  purpose  of  this  study  is  to 
define  the  functional  requirements  for  system  wide  real  • 
time  system  control  applicable  to  the  Defense  Communications 
System  in  the  mid  1980's.  In  order  to  define  these  requirements, 
the  study  is  following  a  logical  progression  of  tasks,  each 
one  building  upon  the  results  of  all  of  the  previous  tasks. 

The  order  of  the  tasks  is  as  follows: 

•  Generate  a  deployment  model  -  a  model  of  the  DCS  deployment 
in  the  mid  80 's  which  removes  planning  uncertainties 

but  which  accounts  for  major  peculiarities  of  the  DCS. 

This  model  provides  a  firm  system  design  against  which 
we  can  develop  and  test  system  control  concepts. 

•  Generate  stress  scenarios  -  a  set  of  system  stress 
situations  which  need  system  wide  control  to  alleviate 
the  stress.  Created  by  analyzing  the  deployment  model 
to  determine  possible  stress  situations. 

•  Select  parameters  -  analyze  the  stress  scenarios  with 
respect  to  the  capabilities  of  the  subsystem  equipment 

to  determine  what  parameters  indicative  of  the  stress  are 
available . 

•  Develop  performance  and  status  assessment,  stress  detection 
and  isolation  techniques  -  develop  the  algorithms, 

data  structures,  and  displays  necessary  to  use  the  parameters 
to  detect  and  isolate  stresses  of  the  types  described 
in  the  stress  scenarios. 
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•  Detail  the  requirements  -  generate  functional  flow  charts 
of  the  performance  and  status  assessment  algorithms, 
analyze  the  communications  flows  required  to  support 

the  algorithms,  and  identify  and  estimate  the  size/cost 
of  any  hardware/ software  additions  or  modifications 
required  to  support  performance  and  status  assessment 
stress  detection  and  isolation. 

•  Develop  control  algorithms  -  determine  a  set  of  practical 
control  responses  which  will  alleviate  the  system  stresses 
of  the  stress  scenarios.  Analyze  the  response  time  of 
the  control  system  and  determine  change  in  parameter 
acquisition  required  to  implement  the  controls. 

•  Quantify  the  benefits  of  controls  -  compare  the  operation 
of  the  DCS  in  terms  of  performance  measures,  availability 
to  critical  subscribers  and  manning  requirements  with  and 
without  overall  control. 

•  Determine  implementation  requirements  -  specify  hardware/ 
software  changes  and  interface  requirements,  and  estimate 
their  size  and  cost,  for  implementing  the  control 
algorithms . 

•  Identify  areas  needing  further  effort. 

This  report  covers  the  first  two  items  -  the  deployment  model 
and  the  stress  scenarios.  There  will  be  three  other  reports 
covering  the  following  subjects: 

Technical  Report  #2  -  Parameter  selection,  Performance  and 

Status  Assessment  Stress  Detection  and 
Isolation  Techniques,  and  details 
of  their  implementation  requirements. 
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Technical  Report  #3  -  Control  algorithm  development, 

performance  analysis. 

Final  Report  -  Summary  of  all  the  tasks,  plus  details 

on  the  control  implementation  requirements 
and  recommendations  for  future  studies. 
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SECTION  II.  DEPLOYMENT  MODEL 


2.1  Purpose  of  the  Deployment  Model 

The  purpose  of  the  deployment  model  is  to  clearly  document  our 
assumptions  regarding  the  characteristics  of  the  DCS  in  the  mid 
1980's.  The  model  also  provides  a  simplified  representation 
which  emphasizes  those  aspects  of  the  DCS  affecting  the 
development  of  system  control  techniques. 

The  time  frame  for  this  study  is  the  mid  1980's.  Since  this  is 
several  years  in  the  future,  there  is  still  some  planning  activity 
on  going  which  affects  the  characteristics  of  the  system  studied 
by  this  study.  The  deployment  model  is  a  mechanism  to  make  this 
study  independent  of  these  planning  activities.  It  represents 
the  best  understanding  of  current  plans  at  the  initiation  of  the 
study,  and  will  be  used  throughout  the  study  as  the  representation 
of  the  DCS. 

The  Deployment  model  is  the  basis  for  the  entire  study.  The 
stress  scenarios  are  situations  involving  failures,  unusual 
traffic  conditions,  or  other  conditions  of  system  degradation 
which  can  exist  in  the  deployment  model.  Development  of  system 
requirements  is  in  turn  based  on  the  stress  scenarios. 

2 . 2  Assumptions 

2.2.1  Time  Frame — The  deployment  model  is  set  in  the  1982-1985 
time  frame.  During  this  period,  the  most  dramatic  changes  planned 
for  the  DCS  will  be  nearing  completion.  The  common  user  switched 
networks  will  be  upgraded  to  the  stage  II  systems  (AUTOVON  II, 
AUTOSEVOCOM  II,  AUTODIN  II).  The  final  phase  of  the  DEB  will 
be  installed,  the  Pacific  Digitalization  will  be  underway,  and 
the  Phase  III  DSCS  Satellite  will  be  in  use.  The  DCS  will 
have  transitioned  from  a  predominantly  analog  to  a  predominantly 
digital  system.  Since  this  study  is  addressing  system  control  for 
the  new  subsystems,  the  1982-85  time  frame  is  the  earliest  time 
frame  applicable. 


2.2.2  Geographical  Area 

The  deployment  model  is  a  respresentaion  of  the  European  backbone. 
The  model  uses  actual  locations  and  contains  a  representation  of  the 
major  features  of  the  European  backbone.  This  approach  is  used 
rather  than  a  purely  abstract  modeling  approach  because  an  abstract 
model  could  not  highlight  the  system  control  problems  caused  by  the 
peculiarities  of  the  DCS. 

The  European  backbone  was  chosen  because  it  is  at  least  as 
complex  as  any  other  segment  of  the  DCS,  and  it  contains  examples 
of  every  type  of  subsystem  used  in  the  DCS.  The  European 
area  is  reflective  of  user  and  mission  objectives  world 
wide. 

System  control  requirements  obtained  by  studying  the  European 
area  can  be  directly  extended  and  applied  to  other  segments 
of  the  DCS.  Therefore,  in  order  to  limit  the  scope  of  the 
deployment  model  to  manageable  size,  the  European  backbone  was 
chosen  for  the  model. 

2.2.3  Communications  Equipment — The  communications  equipment 
assumed  is  consistent  with  the  basic  time  frame  assumption. 

Line  of  sight  microwave  radios  are  assumed  to  be  DRAMA  type 
digital  radios.  First  level  multiplexing  is  assumed  to  be  based 
on  the  T1  signal  format,  with  first  and  second  level  multiplexing 
according  to  DRAMA  type  specifications. 

Digital  tropo  scatter  equipment  is  assumed  on  those  links  for 
which  the  DEB  IV  upgrade  plan  specifies  digital  tropo. 

All  AUTOVON/AUTOSEVOCOM  switches  are  assumed  to  be  AN/TTC-39 
switches.  AUTOSEVOCOM  subscribers  are  concentrated  behind 
SB-3865  unit  level  switches  (ULS) . 

AUTODIN  II  switches  are  assumed  to  be  equivalent  to  the  packet 
switching  node  currently  specified  for  CONUS  installation. 


2.2.4  Performance  Monitoring  Equipment — The  transmission  system 
is  assumed  to  be  monitored  by  ATEC  equipment  as  specified  in 
the  October  1977  ESD  10000  Specification,  and  all  sites  are 
assumed  to  be  suitably  instrumented  to  perform  their  monitoring  function 
This  assumption  is  based  on  the  current  ongoing  LRIP  procurement 
and  the  DCA  ATEC  Management  Engineering  Plan  of  October  1976. 

Because  of  the  capability  of  this  equipment,  other  monitoring 
equipment  such  as  the  Fault  Alarm  Status  Reporting  equipment 
manufactured  by  Harvey  Hubble  Co.  will  either  be  phased  out 
or  integrated  into  ATEC  as  ATEC  is  deployed.  The  performance 
assessment,  control  actions  and  information  flow  currently 
specified  in  the  ESD  10000  is  assumed  to  be  the  pre-existing 
transmission  system  control  that  this  study  is  based  on. 

2.3  Deployment  Model  Data 

The  deployment  model  consists  of  five  sections,  as  follows: 
m  European  Backbone  Topology  and  link  overlay 

•  Common  user  network  connectivity 

•  Critical  User  Deployment 

•  ATEC  Overlay 

•  System  Segment  Detail 

Each  section  consists  of  charts  and/or  tables  covering  the 
information  of  that  section. 

2.3.1  European  Backbone  Topology — This  section  addresses  the 
1982-85  Europe  DCS  Backbone  Topology.  Spurs  and  tails  are 
omitted  to  maintain  simplicity  and  emphasize  backbone  topology, 
however  when  discussing  any  particular  user  it  is  assumed  that 
the  user  circuit  may  traverse  a  tail  circuit  not  shown  on  our 
charts. 


The  European  DCS  backbone  will  consist  of  terrestrial  and 
satellite  communication  links,  connecting  the  United  Kingdom, 
Belgium,  Germany,  Italy,  and  Spain. 

As  shown  in  Figure  2-1,  the  UK  portion  of  the  backbone  consists 
of  all  digital  transmission  links  from  Hillingdon,  England, 
to  Martlesham  Heath,  England,  and  from  Hillingdon  to  Swingate, 
England.  DSCS  trunking  interface  is  provided  by  the  Croughton, 
England,  satellite  terminal.  AUTOVON  switches  are  located  at 
Hillingdon  and  Martlesham  Heath,  and  an  AUTODIN  switch  is 
located  at  Croughton.  UK-continent  connectivity  is  provided 
at  Swingate  and  Martlesham  Heath.  CONUS-UK  connectivity  is 
provided  by  the  Hillingdon  Gateway  AUTOVON  switch,  Croughton 
AUTODIN  switch,  and  Croughton  satellite  terminal.  Insets  1  and 
2  of  Figure  2-1  provides  the  CONUS-Europe  and  Intra-Europe 
satellite  connectivity. 

As  shown,  UK  -  Germany  connectivity  is  provided  by  two  paths; 
Martlesham  Heath  to  Feldberg,  Germany,  and  Swingate  to  Schoenfeld 
Germany.  The  backbone  consists  of  all  digital  transmission  links 
as  shown.  The  Martlesham  Heath  -  Feldberg  portion  is  digital 
tropo  and  diffraction  equipment.  All  other  links  are  line-of- 
sight  microwave.  Germany  contains  AUTOVON  switches  at  Schoenfeld 
Feldberg,  Donnersberg,  and  Langerkopf.  Feldberg  is  the  Gateway 
Switch  with  CONUS  connectivity.  DSCS  trunking  interface  is 
provided  by  the  Landsthul  satellite  terminal  (see  inserts  1  and  2 
of  Figure  2-1) .  An  AUTODIN  switch  is  located  at  Pirmasens. 
Germany  -  Italy  connectivity  is  provided  via  Zugspitze  to  Cima 
Gallina,  Italy,  over  the  DEB  I  system. 

Germany  -  Italy  connectivity  is  provided  by  a  simple  thin  line 
series  of  links  (DEB  I).  Coltano  North  consists  of  all  digital 
transmission  links.  Coltano  South  consists  of  the  upgraded 
486L  tropo  equipment  (AN/FRC-96).  A  microwave  feeder  is  present 
at  Mt.  Vergine  for  Naples  and  DSCS  connectivity.  AUTOVON 
switches  are  located  at  Coltano  and  Mt.  Vergine.  An  AUTODIN 
switch  is  located  at  Coltano.  DSCS  trunking  interfaces  are 
provided  by  the  Coltano  and  Naples  satellite  terminals.  The 


AON  =  AOENAU,  GER. 

ANS  =  AHSBACH,  GER. 

BAN  =  BANK,  GER. 

BOH  =  BRANOHOF.  GER. 

BFM  -  SOUEY  Hill  FARM,  U.K. 
BHR  =  BAUMHOlOER,  GER. 

BNA  =  BEN  AHIN,  BEl. 

BOV  =  BOVINGOON,  U.A. 

BRY  =  B  ARM  AY,  U.A. 

BSN  =  BONSTETYEN,  GER. 


BTl  =  BREt  TSOI,  GER. 

BUN  =  BRUGGEN.  GER. 

CD*  -  COIO  BLOB,  U.A. 

CIM  =  CINA  GAlllNA,  IT. 

CIO  -  coitano.  it. 

CRO  =  CROUGHTON,  U.A. 

CRS  =  CHRISTMAS  COMMON,  U.K. 
ONK  —  DUNKIRK,  U.K. 

DON  =  DONNERSBERG,  GER. 

F  £1  =  F  El  OB  ERG ,  GER. 


FlO  =  FIOBECQ,  BEl. 

FZN  =  FRIOIZHEIM,  GER. 

6T6  =  6REAT  BROMIEY,  U.K. 

HOG  =  HEIOEIBERG.  GER. 

NDN  =  HEIOENHIEM,  GER. 

HIN  =  HIILINGOON,  U.K. 

HKV  =  HOEK  VAN  HOllANO 
HOI  =  HOUTEM.  BEl. 

HST  =  HOHENSTAOT,  GER. 

HUM  =  HUMOSA,  SP. 

CONUS' 
l EASES 


) 


CONUS 

LEASED 


HIGH  BtCOIBE,  U.R, 
AOENIGSTUHL,  GER, 

LAGO  01  P ATRIA,  IT. 
LANOSTUHl,  GER. 

u  ch»oi,  an. 
iniks,  6*. 

lAH6tAA0Pf.  EER. 
HAGTIESMAN  HEATH,  U.A. 
nt.  limbara,  sar. 

BT.  COW*.  IT. 


aim  =  mannheim,  cer. 

IRA  -  IARTINA  FRANCA,  IT. 
NRE  =  NT,  VERGING,  IT. 
«TC=  IT.  Cl  NONE,  IT. 

ITS  =  NT.  SEARA,  IT. 

NUL  =  NUHI,  GER. 

KBS  =  NUERNBERG,  GER. 

NP$  =  NAftES,  IT. 

PAG  =  PAGANEllA,  IT. 


PNS  =  PtNMSBIS,  GER. 

MIN  =  RHEIN  IAIN,  GER. 

SCH  =  SCHOENFEL0,  ICE. 

SGT  =  STUTTGART,  GER. 

SNR  =  SCHRANBERG,  GER. 

SPA  =  SPA  NALCHABPS,  BEL. 
STN=  STEIN,  GER. 

STO  =  STOCASBERG,  GER. 

SRN  =  SCHRETZINGEN,  GER. 
IBG  =  VURZBURG,  GER. 

ICE  =  fESTROZBEKE,  GER. 
RNS=  BORNS,  GER. 

ZUG  =  ZUGSPITZE,  AUS. 


s  TIC-3B 
®  =  AUTOOIN 
=  SAT  EL L I 


SATELLITE  TERM. 


O  a  RABIO  RELAV 


.  SEE  insets 


Figure  2-1.  European  DCS  Backbone  Model  1982-85 


i  GATEVAP 


i  I  SEE  INSETS 


Px 


1 


backbone  terminates  at  Italy  for  the  purposes  of  this  model, 
although  users  in  Greece  and  Turkey  have  access  circuits  to 
the  backbone  there. 

Connectivity  from  Spain  to  UK,  Germany,  Italy,  and  Greece,  is 
provided  by  DSCS  satellite.  Not  shown  in  Figure  2-1  is  the 
Telpak  connectivity  to  UK.  An  AUTOVON  switch  and  satellite 
terminal  is  lcoated  at  Humosa,  Spain. 

Figure  2-2  shows  the  radio  link  overlay  to  the  backbone  topology. 
This  overlay  provides  the  detailed  information  about  the 
individual  links,  of  the  following  types: 

•  Link  distance 

•  Equipment  class-line  of  sight,  tropo,  or  diffraction 

•  Equipment  type  if  known 

Line  of  sight  microwave  radios  are  called  "DCS  radio".  This 
means  that  some  type  of  digital  radio  is  used  on  this  link.  This 
was  done  to  remove  the  remaining  planning  uncertainties  in  the 
deployment  of  radio  equipments, 

2.3.2  Common  User  Network  Connectivity — The  connectivity  of  the 
common  user  networks  (AUTOVON/AUTOSEVOCOM  II  and  AUTODIN  II) 
is  shown  in  Figure  2-3.  This  network  connectivity  is  based  on 
the  latest  planning  information  available.  This  information  is 
the  32  KB  hybrid  TENLEY  alternative  design  for  AUTOSEVOCOM  II. 

No  associated  upgrade  plan  for  AUTOVON  is  available,  but  the 
current  AUTOVON  design  and  the  32  KB  hybrid  TENLEY  alternative 
can  be  rationalized  to  provide  a  model  network. 
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LAF  =  LANGERXOPF,  GEE. 

MEN  -  MARTI ESHEM  HEATH,  U.E. 
MBA  =  MT.  IIMBARA,  SAX. 

MCA  =  MT.  CORNA,  IT. 


MHN  =  MANNHEIM,  SEE. 

MRA  =  MARTINA  FRANCA,  IT. 
ME£=  MT.  V ENGINE,  IT. 
MTC  =  MT.  CIM8NE,  IT. 

MTS  =  MT.  SEERA,  IT. 

MUl  =  HU HI ,  SEE. 

MBS  =  NUERNBERG,  GEE. 

NP$  =  NAPLES,  IT. 

PA6=  PAGANELIA,  IT. 
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Figure  2-2.  Radio  Link  Overlay 
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The  primary  differences  between  the  32  KB  hybrid  alternative 
and  the  current  AUTOVON  are  the  following: 

•  Elimination  of  the  current  Mt.  Pateras  AUTOVON  switch 

•  The  use  of  Langerkopf  as  a  tandem  switch  between  Hillingdon, 
England  and  Mt.  Vergine,  Italy 

•  Extensive  additional  connectivity 

The  connectivity  in  the  deployment  model  was  obtained  by  terminating 
the  current  Donnersberg  -  Mt.  Pateras  truck  at  Mt.  Vergine,  and 
terminating  the  current  Hillingdon  -  Mt*.  Vergine  trunk  at 
Langerkopf  from  both  ends.  Other  than  these  changes,  the  intra 
European  analog  connectivity  remains  unchanged  from  current 
AUTOVON.  The  digital  connectivity  was  obtained  by  combining 
trunks  from  the  32Kb  hybrid  design  such  that  the  topology  was 
identical  to  the  analog  topology  derived  above.  Trans-atlantic 
trunking  for  both  analog  and  digital  is  taken  directly  from  the 
32Kb  hybrid  TENLEY  alternative. 

The  trunk  capacities  are  tabulated  in  Table  2-1.  Figure  2-4 
shows  how  the  trunks  are  routed  on  the  transmission  system 
backbone . 

2.3.3  Critical  User  Deployment — The  critical  user  deployment 
topology  is  shown  in  Figure  2-5.  The  topology  shown  does  not 
constitute  a  complete  or  actual  list  of  DCS  users  of  the  1982-85 
European  DCS,  but  is  representative  of  key  or  critical  users. 

The  selection  was  based  on  high  precedence  traffic  estimates, 
command  structures  and  elements,  and  mission  objectives. 

Critical  users  selected  for  this  study  fall  into  one  or  more  of 
the  following  categories: 
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Table  2-1 


AUTOVON/AUTOSEVOCOM  TRUNK  GROUP 
INFORMATION 


CONNECTED 

SWITCHES 

CAPACITIES 

Trunk 

Group 

Number 

Number 

(Node) 

1  2 

Name 

1  2 

Analog 

Trunks 

Digital 

Trunks 

1 

1 

2 

CON  - 

HIN 

11 

15 

2 

1 

5 

CON  - 

FEL 

11 

39 

3 

1 

9 

CON  - 

MRE 

4 

6 

4 

2 

5 

HIN  - 

FEL 

15 

6 

5 

2 

3 

HIN  - 

MAM 

34 

9 

6 

2 

7 

HIN  - 

LKF 

21 

17 

7 

2 

6 

HIN  - 

DON 

5 

10 

8 

2 

10 

HIN  - 

HUM 

10 

11 

9 

3 

5 

MAM  - 

FEL 

13 

6 

10 

3 

6 

MAM  - 

DON 

12 

7 

11 

4 

5 

SCH  - 

FEL 

13 

5 

12 

4 

6 

SCH  - 

DON 

12 

5 

13 

4 

7 

SCH  - 

LKF 

8 

8 

14 

5 

9 

FEL  - 

MRE 

20 

0 

15 

4 

5 

FEL  - 

DON 

30 

10 

16 

5 

7 

FEL  - 

LKF 

30 

14 

17 

5 

8 

FEL  - 

CLO 

11 

0 

18 

6 

9 

DON  - 

MRE 

22 

4 

19 

6 

7 

DON  - 

LKF 

34 

13 

20 

6 

8 

DON  - 

CLO 

12 

7 

21 

6 

10 

DON  - 

HUM 

12 

6 

22 

7 

9 

LKF  - 

MRE 

7 

6 

23 

8 

9 

CLO  - 

MRE 

9 

3 

24 

9 

10 

MRE  - 

HUM 

18 

4 

Figure  2-5.  Cr 


.  . .. ,  -  - J  ■ 


15 


(1)  Allied  Headquarters. 

(2)  Unified  or  Joint  Headquarters  and  CINC's. 

(3)  Army  Headquarters,  or  Fleet  Headquarters. 

(4)  Corp  or  Numbered  Air  Force  Headquarters. 

(5)  Tactical  Force  Headquarters. 

(6)  Intelligence  Units. 

(7)  Special  Ammunition  Storage. 

(8)  Air  Port  of  Entry  (APOE) ,  Weather  Central  or  Special 
Purpose  Facilities. 

(9)  All  alternate  headquarter  facilities  for  categories  (1) 
through  (3),  above. 

Critical  users  are  displayed  in  terms  of  their  ULS  and  its 
homing.  This  is  not  meant  to  imply  that  AUTOSEVOCOM  II  is  the 
only  critical  user  resource,  but  rather  is  a  convenient  v*ay  of 
showing  the  locations  of  critical  users  in  the  deployment  model. 

2.3.4  ATEC  Overlay — Figure  2-6  shows  the  assumed  ATEC  deployment. 
Sector  and  Node  boundries  are  assumed  as  shown  with  sector 
control  stations  at  the  following  locations: 

•  Hillingdon 

•  Langerkopf 

•  Stuttgart 

•  Coltano 

This  deployment  is  based  on  the  ATEC-LRIP  specifications  through 
option  3  and  DCA  Management  Engineering  plan  of  October  1976. 
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AON  = 
AHS  = 
(AN  = 
•OH  = 
BFH  = 
BHA  = 
BNA  = 
BOV  = 
BAY  = 
BSN  = 


AOENAU,  6EA. 

ANSBACH,  SCO. 

BANK,  OCA. 

•AANDHOF.  EEA. 

BOTlFt  Hill  FARN,  U.A. 
8AUNH01DEA.  GEA. 

BEN  AHIN,  BEl. 
BOVINGOON,  U.A. 

BAAXBAY ,  U.A. 
BOHSIETTEN,  GEA. 


BH  = 
BUN  = 
COf  = 
GIN  = 
CIO  = 
CRO  = 
CAS  = 
ONA  = 
DIN  = 
FEL  = 


BREITSGl.  GEA. 

BAUGGEN,  GEA. 

COIO  BlOB,  U.A. 

CINA  GAL  LINA,  It. 
COITANO.  IT. 

CROUGHTON,  U.A. 
CHRISTNAS  CONNON,  U.A. 
DUNAIRA,  U.A. 
DONNEASBERG,  GEA. 
FEIDBEAG.  GEA. 


FIQ  = 
FZN  = 
CTB  = 
HOG  = 
NON  = 
HIN  = 
KAV  = 
HOU  = 
HST  = 
HUN  = 


FIOBECO,  BEl. 
FRIOIZHEIN.  GEA. 
GREAT  BAOMIEY,  U.A. 
HEIOEIBERG.  GEA. 
HEIDENHIEN,  GEA. 
HILLINGDON.  U.A. 
HOEA  VAN  HOllANO 
HOUTEN,  BEl. 
HOHENSTADT,  GEA. 
HUNOSA,  SP. 


CONUS 

LEASED  ] 
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2.3.5  System  Segment  Detail — Figure  2-7  shows  a  more  detailed 
view  of  a  typical  segment  of  the  model.  The  Vaihingen  user  complex 
is  shown  as  a  typical  critical  user  complex  containing  a  CINC. 

A  representative  set  of  circuits  serving  Vaihingen  is  shown  in 
Table  2-II.  These  circuits  enter  the  DCS  at  the  Vaihingen 
station  and  a  carried  direct  to  Stuttgart  (SGT) .  At  SGT,  some  of 
the  circuits  go  to  FZM,  while  others  go  to  STO.  In  both  cases, 
the  VHN  circuits  share  the  link  with  other  user  circuits  and 
with  trunk  circuits.  The  VHN  circuits  which  went  to  STO  travel 
all  the  way  to  Donnersberg  (DON)  before  being  split  again.  At  KSL 
and  HDG,  other  circuits  again  joint  the  mission  bit  stream. 

The  circuits  sharing  the  HDG-DON  link  are  shown  in  Table  2-III. 

This  is  not  a  comprehensive  list  of  the  circuits  (the  link  has 
over  300  channels)  but  is  a  representative  sample  demonstrating 
the  various  types  of  circuits  on  a  typical  link.  At  Donnersberg, 
some  of  the  circuits  terminate  (the  VON  and  SEVOCOM  access  circuits 
for  example) .  Others  go  to  the  LDN  sattelite  terminal  for  connection 
to  CONUS  via  DSCS.  Still  other  circuits  go  to  Rheinmain.  At 
Rheinmain,  the  weather  circuits  terminate  at  the  Rheinmain  weather 
central.  The  remaining  circuits  travel  to  Feldberg  where  they 
gain  access  to  the  trans-atlantic  cable  for  an  alternate  media 
connection  with  CONUS. 


UF 


Figure  2-7 
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TABLE  2-II  VAIHINGEN  USER  CIRCUITS 


Dedicated  Networks: 


RP-1A  - 

JSC  AN 

- 

Voice  Primary 

- 

VHN 

- 

CONUS  (JCS) 

JSC  AN 

- 

Voice  Alternate 

- 

VHN 

- 

CONUS  (JCS) 

ANMCC 

- 

Voice 

- 

VHN 

- 

CONUS  (ANMCC) 

CINCEUR 

- 

Voice 

- 

VHN 

- 

HDG 

(USAEUR) 

JEMATS 

- 

Data  (300  Baud) 

Pri 

- 

VHN 

- 

CONUS  (JCS) 

JEMATS 

- 

Data  (300  Baud) 
Alt 

- 

VHN 

- 

CONUS  (JCS) 

ABNCP 

- 

Voice  Primary 

- 

VHN 

- 

ABNCP 

ABNCP 

- 

Data  (300  Baud) 

- 

VHN 

- 

ABNCP 

CINCEUR 

- 

Voice  (Pri) 

- 

VHN 

- 

EMS 

(USAFE) 

CINCEUR 

- 

Voice  (Pri) 

- 

VHN 

- 

MPS 

(AFSO) 

CINCEUR 

- 

Voice  (Pri) 

- 

VHN 

- 

SHP 

(NATO) 

CINCEUR 

— 

Voice  (Pri) 

— 

VHN 

— 

LIN 

(Navy  London) 

RP-2A  - 

CINCEUR 

- 

Voice 

RP-3A  - 

WXNET 

- 

Data  (300  Baud) 

- 

VHN 

- 

RHM 

(2d  Wx  Wg) 

RP-3D  - 

WXFAX 

- 

FAX 

- 

VHN 

- 

RHW 

(2d  Wx  Wg) 

Common 

User  Networks 

RP-2B  - 

SEVOCOM 

- 

ULS  Access 

- 

VHM 

- 

DOM 

SEVOCOM 

- 

ULS  Access 

- 

VHN 

- 

LKP 

RP-2D  - 

VON 

- 

VON  Access 

- 

VHN 

- 

LKF 

VON 

- 

VON  Access 

- 

VHN 

- 

DON 

VON 

- 

VON  Access 

- 

VHN 

- 

FEL 

RP-3A  - 

DIN 

- 

DIN  Access 
(1200  Baud) 

- 

VHN 

- 

CRO 

(Admin) 

DIN 

“ 

DIN  Access 
(1200  Baud) 

— 

VHN 

PMS 

(Admin) 

RP-4A  - 

VON 

- 

User  Access  Voice 

- 

VHN 

- 

LKF 

(Routine) 

VON 

- 

User  Access  Voice 

- 

VHN 

- 

DON 

(Routine) 
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TABLE  2-III 

LINK  LOADING:  LINK  MO 30 5  HEIDELBERG  -  DONNERSBERG 

DEDICATED  CIRCUITRY: 


RP-1  - 

VOICE 

8 

DATA 

4 

RP-2  - 

VOICE 

-  11 

DATA 

3 

ULS 

-  21 

RP-3  - 

FAX 

1 

DATA 

-  15 

COMMON  USER 

CIRCUITRY: 

RP-2  - 

VOICE 

(VON)  - 

28 

DATA 

- 

12 

RP-3  - 

VOICE 

(VON)  - 

33 

DATA 

- 

18 

RP-4  - 

VOICE 

(VON)  - 

39 

VOICE 

(DDD)  - 

27 

DATA 

- 

7 

SPARES:  61  Channels 
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SECTION  III.  STRESS  SCENARIOS 


3 . 1  Purpose  of  Stress  Scenarios 

The  purpose  of  the  stress  scenarios  is  to  create  situations 
which  expose  the  requirements  for  system  control,  against  which 
the  system  control  system  can  be  designed  and  its  performance 
tested.  Because  of  the  complex  nature  of  the  DCS  with  its 
multiple  interacting  subsystems  and  global  extent,  a  control 
subsystem  cannot  be  designed  by  simply  listing  each  and  every 
contingency  and  designing  a  system  to  handle  each.  The  number 
of  possible  situations  is  simply  too  large  to  be  managable. 

The  stress  scenarios  are  a  limited  set  of  hypothetical  stress 
situations  which  span  the  types  of  situations  which  would 
exist,  forming  a  complete  but  very  skeletal  representation  of 
the  possible  stress  situations.  The  resulting  scenarios  are 
specific  represenative  examples  of  the  types  of  stress  which  the 
system  control  subsystem  must  respond  to. 

3. 2  Stress  Scenario  Creation  Methodology 

The  stress  scenarios  were  created  by  a  logical  decomposition 
of  the  types  of  stress  which  can  exist  in  the  deployment  model, 
broken  down  by  subsystem  and  by  the  functional  nature  of  the 
stress.  The  resulting  scenario  selection  matrix  is  shown 
in  Figure  3-1.  From  this  matrix,  scenarios  were  developed  which 
demonstrated  different  types  of  system  stress,  with  as  little 
overlap  in  the  nature  of  the  stress  as  possible.  The  resulting 
set  of  scenarios  tends  to  be  weighted  toward  the  upper  left  hand 
corner  of  the  matrix.  There  are  several  factors  leading  to  this 
uneven  distribution  of  stress  scenarios  across  the  matrix  as 
follows: 


•  There  are  more  possible  stress  types  due  to  transmission 
system  failures  than  either  node  equipment  or  traffic 
characteristics 
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•  Common  user  networks  use  the  transmission  system  in 
more  different  ways  than  non  common  user  systems 

•  The  impact  of  stress  on  a  common  user  network  is  more 
likely  to  have  system  level  implications 

•  AUTOVON/AUTOSEVOCOM  uses  more  system  resources  than 
AUTODIN  II 

•  Traffic  stresses  are  not  applicable  to  non  common  user 
systems 

•  In  the  particular  case  of  AUTODIN  II  traffic,  traffic 
controls  already  exist  internal  to  the  network  such  that 
studying  pure  traffic  stress  would  not  be  a  fruitful 
area  of  research.  Traffic  implications  will  be  studied 

in  connection  with  transmission  and  node  equipment  stresses. 

Some  of  the  scenarios  do  not  easily  fit  into  the  simple  matrix 

structure,  but  overlap  two  or  more  categories.  One  scenario  which 

had  to  be  included  is  the  total  failure  of  a  DCS  station.  This 

scenario  overlaps  the  transmission  and  node  equipment  failure 

categories,  but  it  is  important  enough  that  it  could  not  be 

excluded.  Another  way  in  which  scenarios  tend  to  overlap 

category  boundaries  is  that  a  simple  stress  does  not  usually  exist 

by  itself  in  the  DCS  without  some  collateral  stress.  For 

example,  when  an  AUTOVON  trunk  group  fails  due  to  an  RF 

3 

problem,  it  is  likely  that  some  non  common  user  C  network  is 
also  impacted.  Thus  the  stress  which  the  scenario  addresses  are 
not  the  most  critical  in  terms  of  restoral,  and  the  scenario 
ends  up  overlapping  the  categories  of  common  user  voice  and 
non  common  user  networks.  Since  the  scenarios  are  set  in  our 
deployment  model  which  has  characteristics  similar  to  the 
DCS,  this  overlap  cannot  be  avoided. 
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3.3  Use  of  the  Scenarios 


The  scenarios  form  the  foundation  for  the  rest  of  the  study. 

Each  scenario  will  be  examined  to  determine  the  response  of  the 
subsystem  parameters.  The  parameters  of  interest  in  most  cases 
are  alarms  or  alarm  messages  which  occur  when  the  stress  is 
initiated.  Other  parameters  of  interest  are  the  traffic  measurements 
of  the  common  user  networks  such  as  attempts  to  seize  trunks, 
trunk  preempts,  trunk  blockages,  call  attempts  from  specific 
switches,  etc.  The  value  of  these  parameters  will  have  changes 
indicative  of  the  stress. 

By  collecting  the  set  of  parameter  changes  associated  with  each 
stress  scenario,  the  data  correlations  needed  to  isolate  a  particular 
stress  to  the  type  of  stress  and  geographical  location  ce*n  be 
determined.  One  result  of  this  examinations  will  be  that  some 
of  the  indicative  parameters  are  redundant,  and  that  the  time 
required  to  obtain  stress  isolation  depends  on  the  set  of  parameters 
used  to  perform  the  detection  and  isolation.  Traffic  parameters 
in  particular  have  to  be  smoothed  over  some  time  period  in 
order  to  obtain  reliable  indication  of  a  stress.  Also,  different 
traffic  parameters  provide  the  same  basic  information  summarized 
in  different  forms.  As  a  consequence  of  these  characteristics, 
not  all  of  the  indicative  parameters  need  be  used  to  detect  and 
isolate  the  stress.  Only  a  subset  of  the  parameters  are  needed. 

The  parameter  selection  task  will  determine  the  minimum  practical 
set  of  parameters  required  to  detect  the  stress  scenario  stresses. 

After  the  set  of  parameters  needed  for  stress  detection  and  isolation 
have  been  determined,  a  reference  to  the  deployment  model  will 
show  where  these  parameters  are  generated  and  what  location  in 
the  system  control  hierarchy  can  gather  the  set  of  parameters 
together.  This  leads  to  the  communication  needlines  to  get  the 
needed  parameters  from  their  generation  point  to  the  point  of 
stress  visibility. 
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It  The  algorithms  needed  to  perform  the  stress  detection  and  isolation 

function  is  also  determined  by  analysis  of  the  indicating 
parameter  set  for  each  of  the  stress  scenarios.  This  provides 

•• 

a  set  of  processing  requirements  whose  overall  magnitude  can  be 
estimated  and  apportioned  to  modifications  of  existing  equipment 
and  required  new  equipment. 


In  the  second  phase  of  the  study,  control  algorithms  which  relieve 
the  system  stresses  will  be  developed.  This  is  done  by  examining 
each  stress  scenario  and  determining  control  actions  which  respond 
to  the  scenario.  The  control  actions  which  are  demonstratively 
effective  and  practical  can  be  fitted  into  an  overall  algorithm 
framework  for  the  control  of  the  entire  system. 


This  resulting  control  algorithm  will  then  be  tested  against 
the  stress  scenarios  to  determine  its  performance.  Specific 
performance  indicators  include  the  following: 

•  Control  time  response 

•  Resulting  network  performance  measures 

•  Effect  of  the  controls  on  system  availability  to  critical 
users 

•  Changes  in  manning  requirements  resulting  from  control 
application 


These  performance  indicators  will  provide  a  quantitative  measure 
of  the  benefits  obtained  by  the  imposition  of  system  controls. 


Also  as  a  result  of  the  developed  control  algorithms,  the  system 
capabilities  needed  to  implement  the  control  structure  becomes 


evident.  Factors  such  as  additional  hardware/software,  changes 
in  parameters  acquired  during  control  application,  and  interface 
requirements  will  be  determined. 

3 . 4  Introduction  to  Scenario  Data 

The  following  sections  present  the  stress  scenarios.  Three  types 
of  scenario  information  are  presented  as  follows: 

•  A  scenario  list,  describing  the  basic  event  involved  in 
the  scenario  and  why  it  is  included.  This  list  includes 
all  34  scenarios  which  have  been  generated. 

•  For  two  scenarios,  an  example  scenario  solution.  The 
scenario  solution  includes  the  scenario  itself,  a  listing 
of  collateral  stresses  which  would  occur  along  with  the 
specified  stress  in  our  deployment  model,  the  estimated 
time  duration  of  the  stress,  the  indicating  parameters 
and  their  sources,  detection  and  isolation  techniques, 
control  responses  and  a  time  sequence  of  events  caused  by 
scenario . 

•  For  5  scenarios,  the  scenario  details  along  with  indicating 
parameters,  a  summary  of  the  system  impact,  estimated 

time  to  repair,  and  possible  control  actions  are  presented. 

The  control  actions,  time  sequence  of  events,  etc.,  are  preliminary 
ideas  and  are  not  based  on  extensive  analysis.  The  scenario 
solution,  which  contains  these  items,  will  be  developed  over  the 
course  of  the  study.  Actual  scenario  solutions  will  become  part 
of  the  fourth  and  final  report  on  this  study.  The  solution 
examples  shown  are  just  for  demonstration  of  the  concept  of 
scenario  solution. 


3.4.1  Scenario  List — The  following  is  a  list  of  the  scenarios 
which  have  been  developed  as  the  basis  for  system  control.  They 
are  grouped  by  the  subsystem  which  generated  the  stress  scenario. 

Along  with  each  scenario  description  is  the  rationale  for  its 
inclusion  on  the  list. 

AUTOVON/AUTOSEVOCOM  Stresses 

1.  Peak  traffic  load  condition  -  All  system  elements 
functional.  This  scenario  is  the  nominal  system 
situation  without  any  stresses.  It  is  inlcuded  because 
its  the  standard  against  which  other  situations  will  be 
compared . 

2.  Node  outage  -  The  European  gateway  AUTOVON  switch  and 

the  associated  transmission  equipment  at  Feldberg  Germany  is  destroyed. 
This  scenario  is  an  example  of  a  major  inter  area 
connectivity  loss  affecting  both  the  network  node 
equipment  and  the  associated  transmission  links. 

3.  Switch  Failure,  node  intact  -  The  European  gateway 
AUTOVON  switch  at  Feldbergj  Germany  fails  due  to  internal 
equipment  failure.  Emergency  bypass  function  remains 
operable.  The  initial  system  impact  of  this  scenario  is 
the  same  as  Scenario  2, however  in  this  case  only  the 
network  node  equipment  is  affected.  The  associated 
transmission  links  are  intact  and  can  be  used  for 
establishing  a  modified  connectivity  utilizing  the 
transmission  resources  previously  used  by  the  failed 
switch.  Of  particular  interest  is  how  this  scenario 

is  isolated  from  Scenario  2. 
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4 .  Switch  degradation  -  The  Feldberg  Germany  AUTOVON 
switch  experiences  a  partial  digit  receiver  outage. 

This  scenario  is  an  example  of  a  hardware  failure  in 
the  switch  equipment  which  degrades  performance,  but 
in  which  the  switch  is  still  processing  calls. 

5.  Node  outage  -  The  AUTOVON  switch  and  associated 
transmission  equipment  at  Donnersberg  Germany  is 
destroyed.  This  scenario  is  similar  to  scenario  2 
except  that  Donnersberg  is  the  major  intra  European 
tandem  switch  rather  than  a  major  inter  area  switch. 

The  effect  on  the  network  could  be  considerably  different. 

6.  Switch  failure,  node  intact  -  The  AUTOVON  switch  at 
Donnersberg  Germany  fails.  This  scenario  is  the  same 
as  Scenario  5  in  initial  system  impact,  but  since  the 
transmission  system  is  still  operable  the  restoral 
possibilities  are  different. 

7.  Switch  degradation  -  The  Donnersberg  AUTOVON  switch 
experiences  a  partial  digit  receiver  failure.  This  is 
an  example  of  a  common  equipment  failure  which  degrades 
switch  performance,  but  allows  the  switch  to  continue 
processing  calls  at  reduced  capacity. 

8.  Node  isolation  -  the  Feldberg  Germany  switch  node  is 
completely  isolated  by  transmission  system  failure. 

This  scenario  is  related  to  scenarios  2  and  3  in  that 
the  initial  system  impact  is  the  same.  It  is  included 

so  that  isolation  techniques  can  be  developed  to  separate 
this  case  from  scenarios  2  and  3.  The  restoral 
possibilities  are  different. 
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9.  Switch  route  failure  -  All  interswitch  trunks  between 
the  AUTOVON  switches  at  Donnersberg  and  Feldberg  are 
interrupted  due  to  transmission  system  failure.  This 
network  link  is  the  most  heavily  loaded  link  in  Europe, 
both  in  terms  of  traffic  handled  and  number  of  routes 
(source  destination  pairs)  traversing  it.  This  scenario 
provides  a  worst  case  sitation  resulting  from  a  single 
network  link  failure. 

10.  Reduction  in  IST's  -  Fifty  percent  of  the  interswitch 
trunks  between  Feldberg  and  Donnersberg  AUTOVON  switches 
fail  due  to  transmission  system  failure.  This  scenario 
is  similar  to  scenario  9  except  that  instead  of  a 
connectivity  loss,  there  is  a  reduction  in  the  connectivity 
capacity.  Of  paricular  interest  are  the  differences 

in  network  effect  and  indicating  parameters  between  this 
scenario  and  scenario  9. 

11.  Muliple  switch  route  failure  -  All  IST's  between  the 
Donnersberg,  Germany  switch  and  the  switches  at  Langerkopf 
Germany  and  Coltano  and  Mt.  Vergine  Italy  fail  due  to 
transmission  system  failure.  This  scenario  demonstrates 
the  effect  on  the  network  when  a  large  portion  of  the 
intra  Europe  connectivity  in  one  area  is  disrupted  without 
isolation  of  any  of  the  switches 

12.  Multiple  time  phased  switch  failures  -  the  gateway 
AUTOVON  switch  at  Hillingdon  England  fails,  followed  by 
the  failure  of  the  gateway  AUTOVON  switch  at  Feldberg 
Germany  30  minutes  later.  In  addition  to  creating  a 
more  serious  network  failure  than  scenario  3,  this 
scenario  is  inlcuded  to  show  the  interaction  between 
applying  controls  and  further  failures.  This  provides  a 
good  test  of  the  stability  of  the  control  algorithms. 
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13.  Multiple  time  phased  switch  failures  -  the  gateway 
AUTOVON  switch  at  Hillingdon  England  fails,  followed 

by  the  failure  of  the  gateway  AUTOVON  switch  at  Feldberg 
Germany  30  minutes  later.  In  addition  to  creating 
a  more  serious  network  failure  than  scenario  3,  this 
scenario  is  included  to  show  the  interact  between 
applying  controls  and  further  failures.  This  provides 
a  good  test  of  the  stability  of  the  control  algorithms. 

14.  ULS  Failure  -  The  Heidelberg  Germany  unit  level  switch 
(ULS)  fails.  This  scenario  is  an  example  of  a  system 
failure  affecting  only  a  small  group  of  users.  It  will 
demonstrate  how  system  control  can  respond  to  a  failure 
in  critical  subscriber  access  equipment. 

15.  Loss  of  ULS  access  circuits  -  the  access  route  from 

the  Frankfurt  ULS  to  the  Donnersberg  AUTOVON/AUTOSEVOCOM 
switch  is  interrupted  by  transmission  system  failure. 

This  scenario  is  included  to  determine  the  criticality 
of  restoring  access  circuits,  and  to  determine  how  system 
control  can  observe  access  area  stress. 

16.  General  AUTOVON  overload  -  with  all  network  elements 
operating  properly,  traffic  increases  uniformly  the 
network  to  250%  of  the  design  traffic.  This  scenario 
tests  the  capability  of  the  common  user  voice  network 
to  operate  in  an  overload  situation,  and  to  determine 
how  to  detect  traffic  stress. 

17.  Focussed  AUTOVON  overload  -  originating  traffic  at  the 
Donnersberg  switch  increases  to  600%  of  design  capacity. 
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The  rest  of  the  network  is  at  normal  design  busy  hour. 

This  scenario  is  included  to  show  how  traffic  stress  at 
a  single  point  in  the  netwrok  spreads  to  the  rest  of 
the  network,  and  how  this  situation  can  be  detected  and 
controlled. 

Combinations  of  AUTOVON  Stresses 

The  next  five  scenarios  are  combinations  of  the  preceding 
scenarios.  These  combinations  are  included  in  order  to  study 
the  interactions  between  stress  types,  and  to  insure  that,  any  control 
algorithms  developed  don't  aggravate  a  multiple  failure  situation. 

18.  Traffic  overload  and  switch  failure  -  during  the  600% 
overload  of  the  Donnersberg  switch,  the  gateway  switch 
at  Feldberg  fails. 

19.  Traffic  overload  and  multiple  swtich  failure  -  curing  the 
600%  overload  of  Donnersberg  with  the  Feldberg  switch  out 
of  service  the  Hillingdon  gateway  switch  also  fails. 

20.  Switch  and  transmission  failure  -  the  AUTOVON  switch 
at  Schoenfeld  Germany  fails  while  the  Donnersberg 
switch  is  operating  in  a  degraded  mode  and  the  DEB  fails 
between  Zugspitze  Germany  and  Hohenstadt  Germany. 

21.  Inter  area  transmission  failures  -  the  inter  area  DSCS 
links  and  the  TATI  and  TAT 2  cables  fail. 

22.  Traffic  overload  with  switch  and  transmission  failures  - 
The  Hillingdon  switch,  the  transmission  system  between 
Mt.  Corna  and  Coltano,  and  the  European  DSCS  all  fail 
while  the  network  is  carrying  250%  of  design  traffic. 
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Non  Common  User  Network  Stresses 

23.  CINCUSAFE  Voice  Alerting  Network  equipment  failure.  The 
purpose  of  this  scenario  is  to  determine  how  system 
control  can  guarantee  critical  subscriber  connectivity 
in  spite  of  equipment  failures. 

24.  Transmission  failure  isolating  airborne  command  post 

from  ground  command  authority.  This  scenario  demonstrates 
the  responsiveness  of  system  control  to  a  high  precedence 
network  failure  in  a  temporary  network  hookup. 

25.  Multiple  critical  non  common  user  network  outages. 

The  Hillingdon  England  to  Schoenfeld  Germany  DEB  fails 
at  Houtem  Belgium  interrupting  CINCUSAFE,  CINCEUR, 
and  Navy  command  and  control  networks  along  with  other 
critical  networks.  This  scenario  addresses  the  problem 
of  what  happens  when  multiple  critical  networks 
simultaneously  require  restoral. 

System  Control  Stresses 

The  following  five  scenarios  deal  with  stresses  within  the  system 
control  subsystem.  These  stresses  should  not  affect  the  operation 
of  any  other  subsystem  since  the  DCS  should  continue  to  operate 
regardless  of  any  faults  in  system  control.  These  scenarios 
demonstrate  how  the  system  control  function  is  independent  of 
DCS  operation. 

26.  DCAOC  isolated  from  ACOC  -  the  ACOC  at  Vaihingen  Germany 
is  isolated  from  world  Hq.  by  the  loss  of  on  base  cable. 
This  scenario  demonstrates  that  the  area  system  control 
functions  can  be  accomplished  independently  from  world 
Hq. 
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27.  ACOC  destroyed  -  The  European  ACOC  at  Vaihingen  Germany 
is  destroyed.  This  scenario  demonstrates  the  ability 
of  the  system  to  operate  with  a  major  control  point 
destroyed. 

28.  Node  isolated  -  Donnersberg  nodal  control  station  is 
isolated  from  the  sector  control  it  reports  to  (Langerkopf) 
by  a  failure  in  telemetry  equipment.  This  scenario 

is  included  to  examine  the  properties  of  the  system 
control  system  when  a  prime  information  transfer  path 
is  interrupted. 

29.  Sector/Area  isolation  with  switch  failure  -  while 
Langerkopf  is  isolated  from  area  due  to  a  telemetry 
failure,  the  AUTOVON  switch  at  Donnersberg  (which  is 
in  Langerkopf  sector)  fails.  The  purpose  of  this 
scenario  is  to  test  the  sensitivity  of  the  control 
system  to  losses  in  communications  capability. 

30.  Multiple  Sector  Failures  -  Sectors  at  Langerkopf  and 
Coltano  fail  sequentially  for  unrelated  reasons.  This 
scenario  demonstrates  the  effect  of  returning  to  manual 
procedures  for  a  temporary  time  period. 

AUTODIN  Stresses 

The  following  scenarios  deal  with  AUTODIN  II  stresses.  This 
network  is  very  self  controlling  in  that  it  has  its  own  network 
control  center  which  performs  some  control  functions,  and  that 
it  was  designed  using  a  self-adaptive  routing  strategy  and 
traffic  control  protocols  to  prevent  lockups.  The  only  type  of 
system  control  left  to  be  accomplished  is  the  addition/restoral 
of  connectivity.  The  scenarios  included  in  this  list  emphasize 
this  aspect  of  system  control. 
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31.  The  Pirmasens,  Germany  AUTODIN  II  packet  switching  node 
(PSN )  is  completely  destroyed  during  peak  traffic. 

This  scenario  was  included  to  study  the  effect  of  a 
major  equipment  failure  in  DIN  II. 

32.  The  56  KB/sec  trunk  between  the  PSN's  at  Pirmasens 
Germany  and  Croughton  England  is  disrupted  by 
transmission  system  failure.  The  purpose  of  this 
scenario  is  to  study  how  to  detect  and  restore  AUTODIN 
transmission  faults. 

33.  The  56Kb/sec  trunk  between  the  Andrews  PSN  and  Croughton 
PSN  is  disrupted  due  to  a  failure  of  leased  facilities. 
The  purpose  of  this  scenario  is  to  demonstrate  the 
difference  between  intra  Europe  failures  and  inter 

area  failures. 

34.  All  intra  Europe  AUTODIN  trunks  are  disrupted  by 
unrelated  transmission  system  faults.  This  scenario 
is  included  to  show  the  effects  of  major  transmission 
system  stress. 

3.4.2  Scenario  Solution  Examples — Scenario  9  -  Route  failure 

I.  Synopsis  -  The  RF  link  between  Donnersberg  and  Rhein  Main 
Germany  fails  due  to  antenna  malfunction.  This  link 
was  chosen  for  this  scenario  since,  in  our  deployment 
model,  it  interrupts  the  most  heavily  loaded  intra 
European  AUTOVON/AUTOSEVOCOM  trunk  group.  Therefore 
the  DCS  experiences  the  highest  stress  level  of  any 
single  AUTOVON/AUTOSEVOCOM  trunk  group.  The  specific 
failure  mode  is  an  example  of  the  type  of  failure  that 
could  cause  this  stress.  Many  other  failure  modes 
exist  which  would  lead  to  the  same  scenario. 
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II. 


III. 


IV. 
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Colateral  Stress  -  According  to  our  deployment  model, 
the  following  system  stresses  also  exist  if  that  link 
fails : 

Command  and  control  non  common  user  voice  circuits 
between  Ramstein  and  Berlin,  and  Ramstein  and 
Rheinmain  are  interrupted 

Rheinmain  AUTOVON  users  access  circuits  are  interrupted 

The  access  circuits  from  Frankfurt  ULS  to  Donnersberg 
are  interrupted.  Frankfurt  still  has  network 
access  via  Feldberg 

The  weather  FAX  network  is  interrupted  except  for 
Feldberg  homed  users 

Estimated  Time  Duration  of  Stress  -  needed  because  in 
come  cases,  the  stress  duration  may  be  shorter  than  the 
control  response  time,  in  which  case  controls  are 
ineffective.  For  this  scenario,  the  estiamted  time 
to  repair  is  6  hours,  based  on  emergency  dispatch  from 
the  Antenna  Maintenance  Group  at  Rheinmain  arriving 
on  the  scene  approximately  1  hour  after  stress  occurrence, 
and  5  hour  repair  time. 

Stress  Indicating  Parameters 

A.  TTC-39  System  Control  Reports — The  TTC-39  switches 
at  Donnersberg  and  Feldberg  would  issue  several 
reports  via  their  system  control  subchannel  as 
specified  in  ICD-004,  relating  to  the  failure 
of  the  trunk  group.  Upon  the  occurrence  of  the 
stress,  the  following  reports  would  be  issued: 


i 
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R30  -  Failure  of  trunk  group  cluster 
R31  -  Loss  of  trunk  group  synchronization 
R52  -  Trunk  group  FIFO  overflow 

Real  time  parameter  reports,  issued  within  10  minutes 
of  stress  occurrence,  which  indicated  the  nature 
of  the  stress,  include  the  following 

R5  -  Calls  incoming  on  trunk  group  parameter 
Call  attempts  drops  to  zero 
Call  attemps  on  alternate  routes  increases 

R27  -  Error  rate  on  framing  channel  reports  out 
out  of  sync 

If  statistical  reports  are  set  to  be  transmitted 
frequently,  the  R41  report  from  the  Rheinmain  ULS 
would  show  no  switch  accesses  from  Rheinmain,  Also, 
the  next  time  the  Donnersberg  switch  performed 
its  loop  continuity  test  to  the  Rheinmain  ULS,  a 
local  alarm  would  be  generated  at  the  Donnersberg 
switch. 

ATEC  Indicators 

1.  Loss  of  received  signal  level  sensed  at  Rheinmain 
and  Donnersberg  by  the  ATEC  ARS  element 

2.  Loss  of  multiplex  framing  sensed  at  Rheinmain 
and  Donnersberg  by  the  ATEC  ARS  element 
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V.  Stress  Detection  and  Isolation 

Correlation  of  the  trunk  group  failure  messages  from 
Donnersberg  and  Feldberg  indicates  a  failure  in  that 
transmission  path.  ATEC  alarm  data  confirms  the 
transmission  failure  and  isolates  the  exact  location. 

VI.  Control  Response 

By  referencing  the  data  base  at  node  and  sector  level, 

2 

system  control  can  determine  that  the  C  and  weather 
FAX  circuits  are  also  disrupted,  and  can  direct  preemption 
and  patching  at  Donnersberg,  Feldberg  and  Langerkopf  to 
restore  those  circuits.  In  order  to  meet  performance 
objectives,  additional  routes  from  Donnersberg  to  Feldberg 
via  Schoenfeld  and  via  Martlesham  Heath  should  be 
activated  in  the  Feldberg  and  Donnersberg  load  without 
requiring  intercontinental  coordination. 

VII.  Scenario  Time  Sequence 

tQ  RF  link  from  Donnersberg  to  Rheinmain  fails 

tQ  +  1  sec  -  Switches  at  Donnersberg  and  Feldberg  issue  trunk  group 
failure  reports 

tQ  +  2  sec  -  ATEC  alarm  reports  of  loss  of  RSL  and  multiplex  framing 

alarm  at  Rheinmain  and  Donnersberg  arrive  at  Feldberg 
and  Donnersberg  nodes  respectively 

t  +  10  sec  -  Switch  reports  arrive  at  area 

t  +  15  sec  -  Area  requests  transmission  status  from  Langerkopf  sector 

t  +  30  sec  -  Langerkopf  reports  failure  of  Donnersberg- Rheinmain 

link  to  area.  Data  base  access  at  Donnersberg  node 
2 

reveals  the  C  and  weather  FAX  collateral  stress, 
and  requests  Langerkopf  sector  to  check  on  the 
availability  of  links  in  the  preplanned  altroute 


t  +  40  sec  -  Area  determines  routing  table  changes  for  Donnersberg, 
Feldberg,  Schoenfeld,  and  Martlesham  Heath  switches, 
and  issues  system  control  messages  to  those  switches 
via  telemetry 

t  +  60  sec  -  Donnersberg  receives  status  of  preplanned  altroute, 
initiates  patching.  Donnersberg  also  sends  patch 
coordination  to  Langerkopf. 

t  +  65  sec  -  Donnersberg  sends  patch  instruction  to  Feldberg  node 
via  Stuttgart  sector 

t  +  70  sec  -  Donnersberg  switch  executes  loop  test  to  Rheinmain 

ULS,  activating  a  local  alarm  at  Donnersberg.  Since 
restoral  activity  has  already  been  completed,  alarm 
is  ignored. 

tQ  +  400  sec  -  Real  time  traffic  reports  from  Donnersberg  and  Feldberg 
indicating  stress  arrive  at  area.  Since  control  action 
is  already  completed,  no  further  action  is  taken 

2 

t  +  600  sec  -  Patching  of  C  and  weather  FAX  is  completed 

t^  (t  +  6  hours)  -  Link  restored 

+  1  sec  -  Donnersberg  and  Feldberg  report  restoral  of  trunk 
group  to  area 

+  2  sec  -  Donnersberg  notifies  Langerkopf  to  return  to  normal 
configuration.  Langerkopf  notifies  Feldberg  via 
Stuttgart. 

+  10  sec  -  Area  broadcasts  message  to  Donnersberg,  Feldberg, 

Schcenfeld,  and  Martlesham  Heath  to  return  to  normal 
routing  tables. 
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Scenario  6  -  Switch  Failure 


I.  Synopsis  -  The  TTC-39  at  Donnersberg  Germany  fails 
due  to  a  switch  control  group  failure  in  combination 
with  a  CPU  failure  such  that  no  switchover  occurs. 

The  station  is  intact,  as  is  the  essential  user  bypass 
function  of  the  switch.  Donnersberg  was  picked  for 
this  scenario  because  it  is  a  tandem  switch  for  more 
routes  than  any  other  switch  -  31  primary,  34  secondary, 
and  7  tertiary,  in  addition  to  having  a  heavy 
originating  load.  Failure  of  Donnersberg  creates  more 
intra  European  system  stress  than  any  other  single 
node  failure. 

II.  Collateral  Stress  -  Since  this  failure  is  a  subsystem 
equipment  failure,  no  other  subsystem  are  affected 

III.  Estimated  Time  Duration  -  One  hour.  Local  maintenance 
personnel  can  repair  the  fault  by  replacing  a  single 
printed  circuit  card. 

IV.  Stress  Indicating  Parameters 

A.  TTC-39  system  control  reports 

CLO , HIN , FEL , HUM , LKF , SCH , MAM ,  and  MRE  will  all  issue 
reports  related  to  the  failure  of  DON.  On 
occurrence  of  the  fault,  the  R30  report  -  Failure  of 
trunk  group  cluster  will  be  issued.  Real  time 
traffic  parameter  reports  also  indicate  the  nature 
of  the  stress,  including  the  following  reports: 

R5  -  Calls  incoming  from  Donnersberg  drops  to 
zero  at  all  adjacent  switches 
Average  number  of  trunks  busy  drops  to  zero 
Attempts  on  trunks  to  Donnersberg  drops  to  zero 
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R27  -  Error  rate  on  framing  channel  indicates 
out  of  sync 

At  the  system  control  point  which  Donnersberg  reports 
to,  the  lack  of  real  time  traffic  parameter  reports 
indicates  a  problem  with  either  the  Donnersberg  switch 
or  the  system  control  telemetry. 

Locally,  the  CPU  failure  would  result  in  a  major  alarm 
at  the  switch  supervisor  position 

Stress  Detection  and  Isolation 

Correlation  of  trunk  failure  reports  from  all  switches 
connected  to  Donnersberg,  along  with  the  failure  of 
Donnersberg  to  provide  its  real  time  report  and  the 
lack  of  any  transmission  alarms  indicates  a  switch 
equipment  malfunction.  This  must  be  done  at  the  area 
level,  since  only  at  that  level  does  the  visibility 
exist  to  correlate  the  messages  form  all  the  connecting 
switches.  Note  that  the  reports  issued  are  very  similar 
to  the  previous  scenario,  although  the  cause  is  much 
different.  It  is  the  correlation  of  the  reports 
from  various  monitoring  points  that  allows  stress 
isolation. 

Control  Response 

All  ULS's  homed  on  Donnersberg  are  dual  homed,  so  no 
control  response  is  necessary  for  a  one  hour  outage. 
Directly  homed  critical  users  (40)  and  high  priority 
users  (90)  can  be  rehomed  to  Langerkopf,  Schoenfeld, 
and  Feldberg  using  transmission  assets  previously  used 
for  trunking.  Trunks  traversing  the  stations  at  Langerkopf 
Schoefeld,  and  Feldberg  can  be  terminated  at  those  switches 
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to  increase  the  connectivity  of  the  remaining  network. 
In  order  to  see  that  the  transmission  assets  can  be 
configured  in  this  manner,  total  network  visibility 
is  needed. 


Contingency  routing  tables  must  be  activated  in  all 
European  switches  to  adjust  to  the  new  connectivity. 


VII.  Scenario  Tim  Sequence 


Donnersberg  switch  fails.  Local  alarm  is  sounded. 

+  1  sec  -  Coltano,  Hillingdon,  Feldberg,  Humosa,  Langerkopf, 

Schoenfeld,  Martlesham  Heath  and  Mt.  Vergine  all  issue 
trunk  failure  reports  relative  to  the  trunk  to 
Donnersberg.  These  reports  enter  the  system  control 
telemetry  system  and  flow  to  area. 


+  10  sec  -  Failure  reports  arrive  at  area. 

Area  correlates  the  reports  and  determines  that  a 
Donnersberg  node  problem  exists. 

+  15  sec  -  Area  request  transmission  system  status  from  all  ATEC 
sectors . 


+  30  sec  -  ATEC  sectors  respond  to  area  that  all  transmission 
assets  are  functioning  normally.  Local  swtich 
personnel  at  Donnersberg  notice  alarm,  activate  the 
critical  user  bypass  and  begin  troubleshooting 
switch- 


+  40  sec  -  Area  issues  routing  table  modifications  to  all 

European  switches  to  bypass  Donnersberg.  Area  issues 
patching  instructions  to  Langerkopf,  Schoenfeld, 
and  Feldberg  to  terminate  traversing  trunks  on  their 
switch  matrices. 
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t  +  15  min  -  All  patching  completed. 

t^  (t  +  60  min)  -  Donnersberg  switch  returned  to  operational  condition 

t^  +  1  sec  -  Switch  on  line  message  transmitted  to  area. 

t^  +  30  sec  -  Area  issues  message  to  all  switches  to  return  to 
normal  configuration. 

t^  +  300  sec  -  All  patches  removed,  messages  reporting  this  are 
forwarded  to  area. 

t^  +  305  sec  -  Area  directs  Donnersberg  to  remove  the  essential  users 
bypass . 

t^  +  330  sec  -  Essential  user  bypass  is  removed  by  Donnersberg  personnel 

3.4.3  Scenario  Details — This  section  contains  the  details 
of  five  of  the  scenarios; 

•  Partial  switch  route  fail: re 

•  ULS  failure 

•  General  AUTOVON  network  overload 

•  ATEC  node  isolation 

•  AUTODIN  intra  Europe  trunk  failure 

Also  included  in  this  section  is  a  preliminary  sketch  of  the 
solution  for  these  scenarios. 
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Scenario  Ten  -  Partial  Switch  Route  Failure 


I.  Synopsis :  First  level  PCM/TDM  multiplex  failures  on  the 
Donnersberg,  Rhein  Main,  Feldberg  transmission  system 
interrupt  one-third  of  the  Donnersberg-Feldberg 
AUTOVON  swtich  analog  IST's. 

II.  Traffic  Level:  Peak  traffic  load  —  Monday,  0800  hours. 

III.  Switch  Equipment:  All  equipment  if  functioning. 

IV.  Connectivity  Status; 

A.  At  zero  hour,  di-group  7  of  Donnersberg  -  Rhein  Main  - 
Feldberg  B  mission  bit  stream  fails  due  to  an  equipment 
malfunction  at  Donnersberg.  This  generates  a  MUX 
alarm  at  both  Feldberg  and  Donnersberg. 

B.  Feldberg  maintenance,  responding  at  zero  +10 
minutes,  believes  it  may  be  his  problem  and  pulls 
a  MUX  card  for  substitution.  In  doing  so,  he 
selects  di-group  6  of  B  mission  bit  stream  by 
mistake,  thus  removing  this  di-group  from  service. 

In  replacing  the  card,  he  uses  the  wrong  card  so 
the  di-group  remains  out. 

C.  The  end  result  is  that  18  of  the  30  analog  Donnersberg  - 
Feldberg  IST's  and  all  digital  IST's  are 

removed  from  service. 


V.  Failure  Indications;  The  following  failure  indicators 

would  be  present  upon  loss  of  the  Donnersberg  -  Rhein  Main 
Feldberg  di-groups. 

A.  ATEC  Loss  of  Multiplex  Framing  Alarms:  The  initial 
failure,  Donnersberg  -  Feldberg,  di-group  7  of  B 
mission  bit  stream  would  appear  as  a  first  level 
MUX  Framing  Alarm  at  both  Donnersberg  and  Feldberg. 

The  second  failure  involving  di-group  6  of  B  mission 
bit  stream  would  produce  the  same  alarms.  Sensing 
stations  would  be  as  follows: 

Reported  to 

Sensing  Station  ATEC  Nodal 

Feldberg  Feldberg 

Donnersberg  Donnersberg 

B.  Overt  AUTOVON  Indicators 
If  the  signalling  channel  is  affected,  Donnersberg  and 
Feldberg  switches  will  issue  the  following  reports: 

a.  Trunk  group  out  of  service 

b.  Failure  of  signalling  on  dead  trunk  reported 

c.  Trunk  group  loss  of  synchronization 

d.  Local  TSB's  may  be  reported  out  of  service 

e.  Error  rate  on  framing  channel  out  of  sync 

f.  Trunk  group  FIFO  overflow  report  may  occur 


Reported  to 
ATEC  Sector 

Stuttgart 

Langerkopf 
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g.  All  traffic  parameters  on  alternate  routes 
between  terminating  switches  show  increased 
traffic  (attempts,  blocking,  preemptions, 
occupancy) . 

If  the  signalling  channel  is  not  affected,  no 
reports  are  issued. 

C.  Subtle  AUTOVON  Indicators 

If  the  signalling  channel  is  not  affected,  the 
following  traffic  parameter  changes  occur: 

1.  Blocking  rate,  preemption  rate,  and  average 
occupancy  of  trunk  group  decrease  due  to 
decreased  holding  time 

2.  Calls  offered  to  alternate  routes  decreases 

If  the  signalling  channel  is  affected,  the  following 
traffic  parameter  changes  occur: 

1.  Blocking  rate  and  preemption  rate  of  affected 
group  increases 

2.  Blocking  due  to  common  equipment  increases  due 
to  the  use  of  inband  signalling 

3.  All  traffic  parameters  on  alternate  routes  shows 
increased  traffic 

VI .  System  Impact 
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TABLE  3-1.  NETWORK  IMPACT  OF  TRUNK  16  FAILURE 
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A.  DCS  Connectivity:  The  multiplex  failures  result 
in  the  loss  of  two  di-groups  (48  channels)  between 
Donnersberg  and  Feldberg. 

B.  AUTOVON/AUTOSEVOCOM :  18  analog  and  10  digital  IST's 

between  the  Donnersberg  and  Feldberg  AUTOVON  switches 
are  impacted.  The  routes  affected  by  the  degradations 
are  shown  in  Table  3-1. 

C.  Command  and  Control:  No  impacted. 

D.  Special  Networks:  1-1/2  hours. 

Estimated  Time  to  Repair:  1-1/2  hours. 

A.  Di-group  6  B  mission  bit  stream  —  30  minutes  for 
detection,  fault  isolation,  and  restoral. 

B.  Di-group  7  B  mission  bit  stream  —  1  hour  for  detection, 
fault  isolation,  and  repair.  This  is  due  to  confusion 
created  by  personnel  error  in  distant  end  maintenance. 

Temporary  Restoration  Possibilities  Control  Actions 

A.  Station:  See  VII.,  above. 

B.  System:  None. 

C.  AUTOVON/AUTOSEVOCOM :  Reconfigure  link  laoding  so  that 
signalling  channel  is  connected.  Change  trunk  group 
size  in  Donnersberg  and  Feldberg  switches  such  that 
affected  digroups  are  not  used. 

D.  Special  Networks:  None  required 
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Scenario 

I. 

II. 

III. 

IV. 

V. 


Fourteen  -  Unit  Level  Switch  (Concentrator  Failure) 

Synopsis :  This  scenario  addresses  the  failure  of  the 
Unit  Level  Switch  (ULS)  at  Heidelberg,  Germany.  This 
ULS  acts  as  a  concentrator,  and  fails  internally 
during  the  peak  traffic  period. 

Traffic  Level:  Peak  traffic  load  —  Monday,  0800  hours. 

Switch  Equipment:  All  European  AUTOVON  switches;  are 
functioning  normally.  The  Heidelberg  ULS  has  failed 
internally. 

Connectivity  Status:  All  DCS  links  and  VF  circuits 
functioning  normally. 

Failure  Indicators; 

A.  AUTOVON  Switch:  The  Heidelberg  ULS  is  homed  off 
of  the  Donnersberg  and  Langerkopf  switches.  Loss 
of  the  ULS  would  create  alarms  at  both  locations 
upon  the  next  execution  of  switch  tech  control 
routines.  Both  switches  generate  loss  of  trunk 
failure  messages  to  their  parent  ATEC  Sector 
(Langerkopf)  upon  loss  of  the  ULS. 

B.  ULS:  Alarm  will  occur  at  the  Heidelberg  ULS  indicating 
switch  failure.  This  alarm  is  detected  by  the  ULS 
operator  and  is  transmitted  via  voice  order  wire  to 
the  Koenigstuhl  ATEC  nodal. 
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VI.  System  Impact:  Fifty  (50)  users  of  the  Heidelberg 
ULS  are  impacted.  The  breakdown  is  as  follows: 

Heidelberg  45  Users 

Schwetzingen  2  Users 

Seckenheim  3  Users 

VII.  Estimated  Time  to  Repair :  1.5  hours  to  fault  isolate 

and  restore  the  Heidelberg  ULS. 

VIII.  Control  Actions  and  Temporary  Restoral  Possibilities: 
To  be  determined.  None  appear  possible. 


w 
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Scenario  Sixteen  -  General  AUTOVON  Network  Overload 

I.  Synopsis :  This  scenario  addresses  the  general  overload 
of  the  entire  European  AUTOVON  network,  brought  about 
by  military  operations. 

II.  Traffic  Level;  250  percent  above  peak  traffic  load  for 
the  entire  European  AUTOVON  network. 

III.  Switch  Equipment;  All  switches  fully  operational. 

IV.  Connectivity  Status;  All  DCS  links  and  VF  circuits 
functioning  normally. 

V.  Failure  Indicators:  There  is  no  failure.  Primary 

indicators  are  the  call  arrival  rates  as  reported  by  the 
switches.  Secondary  indicators  are  blocked  calls, 
preemption  rates,  trunk  group  occupancy,  etc. 

VI.  System  Impact:  AUTOVON  overloading  is  not  a  system 
failure.  Service  may  be  degraded  below  performance 
standards.  In  severe  overload  (probably  much  greater 
than  250%)  network  throughput  decreases  with  increasing 
offered  traffic. 

VII.  Estimated  Time  to  Repair;  There  is  not  equipment 

failure.  This  section  provides  a  brief  chronological 
scenario  of  the  traffic  build  and  reduction. 
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Chronological  Scenario: 


0800  Hours 

0830  Hours 


0845  Hours 


0900  Hours 


0930  Hours 


Network  is  at  peak  traffic  level. 

Military  operations  commence  with 
command  and  control  notifications. 

Network  now  experiencing  peak  traffic 
plus  15  percent. 

Full  administrative  and  command 
control  operations  have  now  driven 
the  network  to  peak  traffic  plus 
150  percent. 

Pyramiding  communications  requirements 
subsequent  to  the  command  and  control 
activities  have  now  driven  the 
system  to  peak  traffic  plus  250  percent. 

Communications  requirements  have  normalized 
and  increased  military  operations 
reach  their  level  of  execution.  Network 
loading  has  now  dropped  to  peak 
loading  plus  75  percent. 


VIII.  Control  Actions  and  Temporary  Restoral  Possibilities: 

It  is  reiterated  that  we  are  not  dealing  with  a  system 
or  network  outage,  but  a  heavy  traffic  overload  placed 
on  the  network  by  increased  military  operations. 
Therefore,  control  and  restoral  actions  are  limited 
to  those  activities  which  can  reduce  the  network 
burden,  or  provide  greater  traffic  throughput. 

Only  those  actions  are  addressed  on  the  following  page. 


A.  Activation  of  additional  IST's:  Additional 
connectivity  may  be  available  on  a  short  time 
basis . 

B.  Inhibit  Route  by  Precedence:  In  severe  overload 
condition  restricting  routine  traffic  to  primary 
routing  only  will  provide  more  network  throughput. 

C.  Line  Load  Control:  In  critical  overload,  routine 
subscribers  will  be  denied  network  access  to  reduce 
the  traffic  load. 
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Scenario  Twenty-Eight  -  ATEC  Node  Isolation 

I.  Synopsis ;  This  scenario  addresses  the  isolation  of  the 
Donnersberg  ATEC  node  from  the  Langerkopf  sector  due  to 
failure  in  the  telemetry  equipment  at  Langerkopf.  The 
purpose  of  this  scenario  is  to  evaluate  SYSCON 
techniques  and  procedures  under  stress. 

II.  Traffic  Level:  Not  Applicable 

III.  Switch  Equipment;  Not  Applicable 

IV.  Connectivity  Status;  All  links  and  circuits  are 
functioning  normally. 

V.  Failure  Indications ;  Loss  of  telemetry  between  Donnersberg 
and  Langerkopf  causes  ATEC  alarms  and  controller  messages 
to  be  generated  at  both  locations. 

VI.  System  Impact:  The  Donnersberg  node  is  isolated  from 

the  Langerkopf  sector.  Data  base  updates  and  instructions 
normally  received  from  the  sector  are  interrupted  and  are 
stored  at  the  sector  fending  restoral  of  telemetry. 
Measurement  and  status  information  nomally  sent  to  the 
sector  are  stored  at  the  Donnersberg  node  until 
telemetry  is  restored.  The  Donnersberg  nodal  can  only 
request  testing  and  measurement  actions  within  its  own 
nodal. 

VII.  Estimated  Time  to  Repair:  1.0  hour  to  dispatch 
maintenance  fault  isolate  and  repair. 
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VIII.  Control  Actions  and  Temporary  Restoral  Possibilities; 

No  control  actions  or  temporary  restoral  possibilities 
exist.  Restoral  can  be  affected  only  through  repair 
of  telemetry  equipment. 


Scenario  Thirty-Two 


w 


Disruption  of  56  KB/S  Intra-Europe 
Interswitch  Trunk 


I.  Synopsis ;  This  scenario  addresses  the  disruption  of 
the  Croughton,  England,  to  Pirmasens,  Germany,  56  KB/S 
AUTODIN  1ST  due  to  a  partial  transmission  system  failure 
at  Schoenfeld  Radio  Relay.  The  purpose  of  this  scenario 
is  to  evaluate  control  and  restoral  actions,  and  SYSCON 
hierarchical  level  of  execution. 

II.  Traffic  Level:  Peak  traffic  load  -  Friday  1700  hours. 

III.  Switch  Equipment:  All  switch  equipment  and  European  PSN 
are  functioning  normally. 

IV.  Connectivity  Status:  Interconnecting  cabling  between 

di-group  1  of  link  M0067  (Muhl-Schoenfeld)  and  di-group 
2  of  link  M0908  (Schoenf eld-Spa  Malchamps  and  Hillingdon) , 
is  inadvertently  cut  by  maintenance  personnel,  interrupting 
all  traffic  exchange.  The  loss  of  this  interconnect 
disrupts  the  Pirmasens-Croughton  1ST. 

FAILURE  INDICATION: 

A.  ATEC :  Due  to  the  nature  of  the  failure  at  Schoenfeld, 
no  ATEC  radio  or  multiplex  alarms  are  generated. 
Contingent  on  ATEC  In-Service  Monitoring  Set  (IMS) 
scanner  configuration,  loss  of  send  signal  at 
Schoenfeld  (in  both  Croughton  and  Pirmasens  direction) 
should  be  detected  during  the  background  scan.  Loss 
of  send  signals  would  be  reported  as  a  threshold 
violation  to  the  ATEC  node  at  Schoenfeld. 
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B.  AUTODIN :  Both  Croughton  and  the  Pirmasens  ASCs  would 
experience  loss  continuity  on  the  56  KB/S  1ST,  with 
loss  of  crypto  synchronization  and  resultant  alarm. 
Assuming  traffic  in  progress  between  Pirmasens  and 
Croughton,  the  NCC  would  get  source  and  destination 
node  timeout  reports  from  both  PSN's. 

Each  PSN's  fault  detection  software  would  also  generate 
failure  reports  to  the  NCC. 

The  Timout  Reports  would  be  incorporated  into  four  NCC 
Data  Management  Software  data  sets: 

•  Switch  timeout  status 

•  Switch  disturbance  summary  (trended) 

•  Network  disturbance  summary  (trended) 

•  Node  timeout  report  file 

The  failure  reports  are  incorporated  into  four  data 
data  sets: 

•  Network  configuration  and  directory 

•  Network  disturbance  summary 

•  Disturbance  suspense 

•  Failure  report  file 


-57- 


The  reception  of  a  failure  report  at  the  NCC  will 
cause  the  operator  to  be  notified  via  an  audible 
alarm,  and  the  network  disturbance  summary  will  be 
displayed  on  the  CRT  indicating  the  cause  of  the 
report. 

V.  System  Impact:  Loss  of  the  Pirmasens-Croughton  56  KB/S 

1ST,  interrupts  the  traffic  flow  between  the  two  switches. 
Message  queues  build  at  both  switches  containing  traffic 
destined  for  users  in  the  Croughton  and  Pirmasens  areas. 

VI.  Estimated  Time  to  Repair:  1.0  hour,  with  ATEC  assistance 
in  the  fault  isolation. 

VII .  Control  Actions  and  Temporary  Restoral  Possibilities: 

With  the  loss  of  the  56  KB/S  1ST,  little  other  than  altroute 
action  can  be  implemented  pending  restoral.  The  following 
altroute  possibilities  exist. 

A.  Altroute  the  Croughton-Pirmasens  56  KB/S  1ST  via 
available  spare  or  pre-empted  circuitry. 

B.  Establish  4.8  KB/S  1ST  via  AUTOVON  dial  up  between 
Croughton  and  Pirmasens  to  allow  traffic  movement 
until  speed  1ST  can  be  restored. 
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